Designing and fabricating electronic systems typically involves many steps, known as a “design flow.” The particular steps of a design flow often are dependent upon the type of electronic system to be manufactured, its complexity, the design team, and the fabricator or foundry that will manufacture the electronic system from a design. Typically, software and hardware “tools” verify the design at various stages of the design flow by running simulators, hardware emulators, and/or formal techniques, and errors in the design are corrected or the design is otherwise improved.
Initially, a specification for a new electronic system can be transformed into a logical design, sometimes referred to as a register transfer level (RTL) description of the circuit. With this logical design, the electronic system can be described in terms of both the exchange of signals between hardware registers and the logical operations that can be performed on those signals. The logical design typically employs a Hardware Description Language (HDL), such as System Verilog or Very high speed integrated circuit Hardware Description Language (VHDL).
The logic of the electronic system can be analyzed to confirm that it will accurately perform the functions desired for the electronic system, sometimes referred to as “functional verification.” A design verification tool can perform functional verification operations, such as simulating, emulating, and/or formally verifying the logical design. For example, when the design verification tool simulates the logical design, the design verification tool can provide transactions or sets of test vectors, for example, generated by a simulated test bench, to the simulated logical design. The design verification tool can determine how the simulated logical design responded to the transactions or test vectors, and verify, from the results of the simulation, that the logical design describes circuitry to accurately perform functions.
As circuits and their corresponding logical designs become more complex, the task of functional verification becomes increasingly difficult to manage and accomplish. For example, this complexity can include logical designs including multiple power domains, multiple clock domains, multiple different types of resets having various characteristics, or the like. Given this complexity, many “bugs” or design flaws can be left unexposed by conventional simulation. One such “bug” can occur when signals crossing clock domains include glitches, or temporary spikes in signal value corresponding to an incorrect value. These signal glitches, when crossing clock domains, may be captured or latched by a register, which can cause logic failures.
Verification engineers have attempted to identify a presence of combinational logic capable of inducing the glitches in signals traversing between clock domains in a variety of ways. For example, the verification engineers can sample the signal path crossing between clock domains during simulation, and then utilize the samples to identify a presence of glitches in the signal path. Due the asynchronous nature of signal paths crossing clock domains, many simulators have difficulty sampling the signal paths at the times when glitches may be present. Some verification engineers have elected to write assertions to check if the simulators are sampling the signal paths at the correct time, but the results of sampling checks are often not accurately captured by the simulator.
Verification engineers have also performed static checks on the circuit design to identify portions of the circuit design that may be susceptible to inducing glitches in signals traversing a clock domain crossing. These static checks typically include flagging every clock domain crossing that contains combinational logic in its path in the circuit design for manual inspection by the verification engineers. While manual inspection can identify combinational logic capable of inducing signal glitches, the procedure is error-prone and time-consuming.